Cumulative content of Working Group Meetings in 2025

Date: 22/04/2024
Participants: Natalie Muric
Model and note editor: Achilles Dougalis

Agenda

Discussion

  • Announces vs. RefersTo #781 discussion

    • The reply to the question in the above Github discussion was discussed, and the proposed predicates depicted on the table below were reviewed. It was mentioned that predicate epo:announcesRole from class epo-not:ContractModificationNotice to class epo:AgentInRole should be changed to epo:refersTo as it was discussed that a Modification Notice always refers to a pre-existing procedure with defined lots and roles, and does not introduce new roles.

llT8DyPHptno7bo1AAAAAElFTkSuQmCC

  • The eQualification ORSD and eAwarding ORSDs were reviewed and discussed.

    • It was decided that the eQualification module should only represent the qualification sub-proccess used both by open and closed (mini competition) procedures.

    • As a result, eQualification, eAwarding and eEvaluation ORSDs were modified. Specifically:

      • eEvaluation: The qualification part after the evaluation process was removed from the ORSD.

      • eAwarding: The qualification part was replaced by a reference to the eQualification module.

      • eQualification: The description of the closed procedure was removed from eQualification, keeping only the qualification part. A detailed description of qualification for both closed and open procedures was written.

Action Points

  • Create a ticket: Predicate epo:announcesRole from class epo-not:ContractModificationNotice to class epo:AgentInRole to be changed to epo:refersTo.

  • To update the diagram of the offering party to include Candidate and any other roles currently missing from the diagram.

  • To continue fixes in the eQualification ORSD.

Working Group Meeting

Date: 15/04/2025  
Participants: Natalie Muric, Pietro Palermo
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

Discussion

  • The eOrdering requirements were discussed:

    • All the new diagrams were reviewed.

    • OrderCancellation CM diagram: To delete generalizations to OrderCancellation so it is harmonized with the OrderChange CM diagram.

    • dct:Issued attribute representing both date and time was discussed. Thw WG concluded that It is ok to just use dct:Issued in the Ontology to represent both date and time.

    • It was decided that the Implement Item property code for ePO #773 ticket can be moved to ePO 5.1.0.

  • Announces vs. RefersTo #781 discussion: The WG decided to create a spreadsheet that indicates what predicate should be used for each Notice – Entity pair.

Action Points

  • Update the Mappings to the eOrdering data models.

    • Update OrderCancellationConfirmation and OrderCancellationChange mappings.

    • Update the concepts related to the Time Ontology.

  • Create a Github Issue: The ESPD should become independent of the ESPD request. link it to #701 Remove Predicate epo-sub:relatesToESPDRequest

  • To follow up with the open Github issues on eCatalogue.

  • create a Github Issue: We need a way to represent indefinite durations for standard forms for 5.2.0.

  • Create a spreadsheet for Announces vs. RefersTo #781

  • Create a Github issue to model E1 (premarket consultation) notice.

  • To review Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726.

Working Group Meeting

Date: 08/04/2025
Participants: Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Discuss the mappings between fields from the TC440 Order Data model to ePO concepts.

Discussions

  • OrderResponse field BT-ORL-5 Maximum backorder quantity was discussed:

    • Predicate epo-ord:hasBackOrderQuantity [0..1] was added from epo-ord:OrderResponseLine to epo:quantity.

  • OrderResponse field BT-ROL-2 Referenced Order line status code was discussed.

  • OrderCancelation

    • OrderCancelation became a postAwardDocument.

    • Predicate Linking epo-ord:OrderCancellation with Order was changed from epo:isSubmittedFor to epo-ord:isSubmittedForOrder.

    • It appears that we do not need the predicates pointed out below. This needs to be discussed further in a future WGM.

DxW6yApQovamAAAAAElFTkSuQmCC

  • OrderChange

    • OrderChangeRejection and OrderChangeConfirmation became PostAwardDocuments.

    • To compare the implementations ofOrderChange and OrderResponse in a future WGM and decide what is the better one.

17eEuaFPcIgAAAABJRU5ErkJggg==

  • It was agreed that the OrderResponseConfirmation, OrderResponseRejection and OrderResponseSimple data-models can be modelled using epo-ord:OrderResponse.

  • For attribute epo-ord:hasDownloadURL, the following definition was added: "Location where the resource can be downloaded".

  • ePO tickets 743 and 611 were described, answered and closed.

Working Group Meeting

Date: 03/04/2025  
Participants: Natalie Muric, Thomas Peterson, Kok Wim
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Discuss the mappings between fields from the TC440 Order Data model to ePO concepts.

Discussions

  • Field BT-OHI-6 : The field represents a reference of the Order. We are going to delete the existing epo-ord:hasCustomerReference attribute, and turn it into a predicate connecting epo:PostAwardDocument to adms:Identifier.

    • Definition: "A supplementary reference used to identify the Buyer’s internal process."

yjxf5WQQJrRpmFRAAAAAElFTkSuQmCC

  • Field BG-ADR: Question: Is this a Document, or a PostAwardDocument?

    • Answer: It should be placed at the level of the Document.

  • Field BG-IPSP: What role should we use for that? We should create the epo-ord:Invoicee role and not just use buyer as mentioned in https://docs.ted.europa.eu/epo-wgm/notes/2023-02-21-eord.html#_agenda.

    • Class epo-ord:Invoicee was created as a subclass of the Acquiring Party.

      • Definition: "The Role of an Agent who receives and processes the Invoices."

g8QZVW4Vq1HsQAAAABJRU5ErkJggg==

  • Predicate epo:specifiesInvoicee was added.

caCADlQAAAAAAAXUAA9IGZ2UVCAB43tWqvAPsACADlQAAAAAAAXUAA9AEIwH4GAkA5EAAAAABAFxAAfQACsJ+BAFAOBAAAAADQBQRAH4AA7GcgAJQDAQAAAAB0AQHQByAA+xkIAOVAAAAAAABdQAD0AQjAfgYCQDkQAAAAAEAXEAB9AAKwn4EAUA4EAAAAANAFBEAfgADsZyAAlAMBAAAAAHQBAdAHIAD7GQgA5UAAAAAAAF1AAPQBCMB+BgJAORAAAAAAQBcQAH0AArCfgQBQDgQAAAAA0AUEQB+AAOxnIACUAwEAAAAAdAEB0AcgAPsZCADlQAAAAAAAXUAA9AEIwH4GAkA5EAAAAABAFxAAfQACsJ+BAFAOBAAAAADQBQRAH4AA7GcgAJQDAQAAAAB0AQHQByAA+xkIAOVAAAAAAABdQAD0AQjAfgYCQDkQAAAAAEAXEAB9AAKwn4EAUA4EAAAAANAFBEAfgADsZyAAlAMBAAAAAHQBAdAHIAD7GQgA5UAAAAAAAF1AAPQBCMB+BgJAORAAAAAAQBcQAH0AArCfgQBQDgQAAAAA0AUEQB+AAOxnIACUAwEAAAAAdAEB0AcgAPsZCADlQAAAAAAAXUAA9AEIwH4GAkA5EAAAAABAFxAAfQACsJ+BAFAOBAAAAADQBQRAH4AA7GcgAJQDAQAAAAB0AQHQByAA+xkIAOX8H1mYLgD6ti2QAAAAAElFTkSuQmCC

  • Predicates epo:exposesInvoiceeChannel, and IndicatesInvoiceeContactPoint from epo:Buyer were removed.

YrXkevoI0EQAAAABJRU5ErkJggg==

  • Field BT-ODI-1-4-8

    • At the level of epo-ord:DeliveryInformation, attribute epo-ord:hasDeliveryEmail was created.

      • Definition: "The electronic address to which the products or services are to be delivered."

  • Field BG-ODT: the solution provided in the ePO Github issue #623 was explained.

    • Attribute epo:GeneralDeliveryTerm was renamed to epo:hasGeneralDeliveryTerm

    • locn:geographicName should be used for BT-ORDT-3 instead of an identifier.

    • Field BT-ORDT-4 was discussed.

      • epo-ord:hasRequestedShippingPriority was removed from epo-ord:DeliveryInformation, and was put under epo-ord:DeliveryAgreement

  • ePO Github issue #767 was discussed and marked as completed for the fields:

    • BT-OAI-6-4 "Order allowance Exemption reason text"

    • BT-OAI-6-5 "Order allowance VAT exemption reason and specification code".

    • BT-OCI-6-4 "Order charge Exemption reason text"

    • BT-OCI-6-5 "Order charge VAT exemption reason and specification code".

  • Field BT-OTO-5 in Github Issue #696 was discussed, updated and closed.

  • Field BT-OL-6-5 should only be used in the Order Change. Was removed.

  • Field BT-OL-10 implemented as discussed in Github issue #766, and the solution provided was acknowledged by the Working Group.

  • Field BT-OL-11: It was decided to re-use attribute epo-ordhasAccountingCost at the level of the OrderLine.

  • Field BT-II-10-3: To create a GitHub issue to ask about the ItemNameCode. (Code for the item property according to a property code system)

  • Fields: BT-OAHI-10, BT-OCAREHI-10, BT-OCACOHI-10, etc. :It was agreed that we shall use attribute epo:hasAdditionalInformation at the level of epo:Document for these fields.

  • The diagrams for the OrderChange, OrderCancellation and OrderAgreement were presented:

A4bXTOkFX8dqAAAAAElFTkSuQmCC

Order Change diagram

wPJPKV+dT58eAAAAABJRU5ErkJggg==

Order Cancellation diagram

weBi1DXscWlKgAAAABJRU5ErkJggg==

Order Agreement diagram.

  • Regarding Order Response:

    • Proposal to change epo-ord:hasAcceptanceStatus predicate from OrderResponseInformation to epo-ord:hasStatus

    • Predicate ImplementsContract from OrderResponse was deleted as it was not in use.

LMfxFoJmEOwAAAAASUVORK5CYII=

Action Points

  • To Reply to #695

  • Add a github issue for Item Property code.

Working Group Meeting

Date: 27/03/2025  
Participants: Victorio Bentivogli, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Discuss the eOrdering module extensions:

Discussions

The Order Response, Change, Agreement and Cancelation data models were discussed and their respective ePO diagrams were presented.

  • The Order Cancelation diagram was developed, containing the new Classes epo-ord:Cancellation, epo-ord:OrderCancellationRejection and epo-ord:CancellationConfirmation as seen on the diagram below:

AIN3WTTwW1T8AAAAAElFTkSuQmCC

  • OrderAgreement: The Working Group struggled to understand this concept, and what is the difference with Order. After consulting PEPPOL’s OrderAgreement data model, the Working Group concluded that Order Agreement is an alternative Order.The diagram for the Order Agreement is displayed below:

ui7miwkyUYoAAAAASUVORK5CYII=

  • Predicate epo-ord:comprisesOrderLine, linking epo-ord:Order to epo-ord:OrderLine became epo-ord:comprises in order to be used by all subclasses of epo-ord:Order and epo-ord:OrderLine.

  • epo-ord:hasStatus was added at the level of epo-ord:OrderLine so it can be referenced by the epo-ord:OrderChangeLine if needed.

  • Classes epo-ord:OrderChangeRejection and epo-ord:OrderChangeConfirmation were added as seen in the diagram below:

pPgAAAABJRU5ErkJggg==

Working Group Meeting

Date: 25/03/2025  
Participants: Victorio Bentivogli,Veit Jahns, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

Discussions

  • Issue #744 was discussed: Attribute epo:hasCalculationMethod was added to the class epo-cat:EnvironmentalEmissionInformation.

iRYaYTYAAAAAElFTkSuQmCC

  • Issue #730 was discussed:

    • We use the same Attribute for eOrdering and eCatalogue, both at the level of the OrderResponse, Catalogue Response, CatalogueResponseLine thus a more general definition is required.

    • Definition of epo-ord:hasResponseDescription was modified to: "Explanation of the response".

  • Issue #722 was discussed: The expert for the Catalogue concepts was pointed to the issue for review.

  • Issue #549 was discussed: epo:hasProcurementScopeDividedIntoLot Definition was updated to: “Defines Lot”.

  • Issue #605 was discussed: it was agreed to remove attribute epo:hasOJSType and change the datatype for epo:hasOJSIssueNumber from xsd:integer to rdf:PlainLiteral

  • Issue #662 was discussed: Since in eForms, the Subcontractors are referenced at the level of the Organization, as of ePO 5.0.0 the following implementation is adopted:

    • Removing epo:foreseesSubcontractor and epo:specifiesSubcontractors predicates between epo:Tender and epo:Subcontractor and use org:Organization epo:foreseesSubcontractor epo:Subcontractor.

    • Keeping epo:Contractor epo:foreseesSubcontractor epo:Subcontractor and epo:Contractor epo:hasSubcontractor epo:Subcontractor since they might be used in a future use-case.

AZFxB7F3tJEMAAAAAElFTkSuQmCC

  • Issue #610 was discussed: The name of the concept epo:VehicleInformation was changed to epo:CleanVehicleDirectiveInformation as depicted below:

wNa0YAQsC4bRQAAAABJRU5ErkJggg==

  • Issues #743 and #443 were discussed: epo-ord:hasAcceptanceStatus was renamed to epo-ord:hasResponseStatus.

wO0FnrBtq2jjQAAAABJRU5ErkJggg==

  • Issue #623 was discussed:

    • The ePO team prefers not to have the at-voc-new:document-type code list on the level of epo:Document, but a new Class for each of the concepts mentioned in the code-lists.

    • It was argued that currently there is no need to change this as this code list is used to reference a number of additional documents.

    • Maybe that code list could be trimmed so we can only have relevant values.

    • There should be examples of that codelist.

    • Predicate epo:documentUsedInPublicProcurement was renamed to epo:hasDocumentType.

y0MS4AAAAASUVORK5CYII=

Action Points

  • Create a ticket to get all the values that are relevant to procurement that the at-voc-new:document-type code list contains.

  • Fix Issue #623 and create another issue about Document status if needed.

Working Group Meeting

Date: 20/03/2025  
Participants: Victorio Bentivogli Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Discuss epo 5.0.0 github issues.

Discussion

It was discussed that a new alignment with PEPPOL for eORdering effort has started, regarding Order change, Order response and Order Agreement.

Issue #641 was discussed

  • epo:hasCurrency cardinality was changed from [0..1] to 1.

0SEAAAAAOAvoEAAAAOBLoEMAAACAL4EOAQAAAL4EOgQAAAD4EugQAAAA4EugQwAAAIAvgQ4BAAAAvgQ6BAAAAPgS6BAAAADgS6BDAAAAgC+BDgEAAAC+BDoEAAAA+BLoEAAAAOBLoEMAAACAL4EOAQAAAL4EOgQAAAD4EugQAAAA4EugQwAAAIAvgQ4BAAAAvgQ6BAAAAPgS6BAAAADgS6BDAAAAgC+BDgEAAAC+BDoEAAAA+BLoEAAAAOBLoEMAAACAL4EOAQAAAL7kP+Krerdl9SmeAAAAAElFTkSuQmCC

Issue #643 was discussed:

  • epo-cat:hasTaxScheme cardinality was changed from [0..1] to 1.

8TQAAAABJRU5ErkJggg==

Issue #575 was discussed:

  • Properties epo-ful:hasOnCarriageShipmentStage and epo-ful:hasPreCarriageShipmentStage were deleted.

FlMgAAAABJRU5ErkJggg==

  • Property epo-ful:hasMainCarriageShipmentStage was renamed to epo-ful:hasCarriageShipmentStage.

  • Definition of epo-ful:hasCarriageShipmentStage was modified to: "The Shipment Stage for the last mile covered in a transport chain."

8D6gYB+Yr96bQAAAAASUVORK5CYII=

Issue #765 was discussed:

  • The main question is, if from a Business point of view, the Financing and Payer party should be at the level of epo:LotResult or at the level of the Result Notice.

  • They were put on the epo:LotResult Level because not all Lots mentioned in a Result Notice are always awarded.

  • It was discussed that this issue could be treated in ePO 5.1.0.

  • Finally, it was agreed that epo:BudgetProvider and epo:PaymentExecutor should be mapped using epo:AgentInRole epo:conceptualisedBy epo:Lot. It can also be used for a epo:PlannedProcurementPart and epo:Procedure since they all are subclasses of epo:ProcurementElement.

The following eForms fields were discussed in the context of their mappings to ePO:

  • Field OPT-093-Review: An Identifier for a Review. It was not defined well, and no one has used this as of now (no data).

  • Fields OPA-36-Lot-Number, OPA-98-Lot-Number, OPA-36-Part-Number: These are Attributes of other fields currently not in use in eForms. They were designed to hold a number, but were discarded because eForms typically uses 2 fields to do this: One field has the measure and is coupled with another field that has the unit value.

Issue #549 was discussed:

  • Another option is to rename epo:hasScopeDividedIntoLot to epo:aggregatesLot.

  • The issue was left open to be discussed in a future WGM.

Issue #763 was reviewed.

  • There was a second request in the ticket:

    • "Also, the epo:definesTenderProcessor, epo:definesTenderReceiver, epo:definesProcurementProcedureInformationProvider and epo:definesOfflineAccessProvider and some new epo:definesXXX properties could be added to link all the above roles to epo:PlannedProcurementPart, without the need to instantiate the epo:AccessTerm and epo:SubmissionTerm classes."

    • The following answer was given to the above question: "Regarding the second request, since those roles are defined at the level of epo:AccessTerm and epo:SubmissionTerm in the case of a epo:Lot, we will keep the same implementation for a epo:PlannedProcurementPart."

Issue #764 was briefly discussed.

  • A a number of attributes and Predicates were moved from the level of epo:ProcurementObject and epo:Lot, to the level of epo:ProcurementElement, in order to them usable by epo:PlannedProcurementPart.

  • A more detailed explanation on the changes will be given as a comment of Issue #764.

cRz5KAAAAAElFTkSuQmCC

Diagram showing the Ontology before the modification

EoMjaW3VSJgAAAABJRU5ErkJggg==

Diagram showing the Ontology after the modification

Action Points

  • To discuss #765 with the eForms team.

    • The main question is, if from a Business point of view, the Financing and Payer party should be at the level of LotResult or at the level of the Result Notice:

    • Edit: It was agreed that the epo:BudgetProvider and the epo:PaymentExecutor should be mapped using epo:AgentInRole epo:conceptualisedBy epo:Lot. It can also be used for a epo:PlannedProcurementPart and epo:Procedure since they all are subclasses of epo:ProcurementElement.

Working Group Meeting

Date: 18/03/2025  
Participants: Victorio Bentivogli, Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Discuss new Github Issues related to eForms.

Discussions

Issue #757 was discussed

  • After checking eForms fields BT-808 and BT-807, predicate epo:specifiesReviewRequester was added on the level of epo:ReviewDecision.

  • Maybe in the future we can replace predicates epo:specifiesReviewer and epo:specifiesReviewRequester with just an epo:specifiesRole predicate.

Ue6HYh50Qz9jKIgDgHcMwWv7oeTbFHwE3mI4BkErnrt96uLG5LR8AQONwG1BoigCAd7gNqCJ0DACrUsnmCia32gCgEgIAmvohn816vEIuV7G4L6wfEQCK0DEAAEBBBEBV4lUmHI3vBqO83CvrP2y9PojmltZCAAAAAElFTkSuQmCC

Issue #756 was discussed.

  • Class epo:ReviewInformation was created.

  • Predicate epo:relatestoEFormsSectionIdentifier was added with domain epo:ReviewInformation and range adms:Identifier.

  • Attribute epo:hasElementReference was removed from epo:Document and added to epo:ReviewInformation.

  • Predicate epo:resolvesReviewRequest was renamed to epo:answersReviewRequest.

S3AwCAfggARREAkggAAACACAJAUQSAJAIAAAAgggBQFAEgiQAAAACIIAAURQBIIgAAAAAiCABFEQCSCAAAAIAIAkBRBICkX1C8nmEmaczjAAAAAElFTkSuQmCC

Issue #761 was discussed.

  • Indeed code list at-voc:received-submission-type seems to be redundant.

  • All the values of the code list were analysed and it was made sure that for each value of the code list there is an attribute on class epo:SubmissionStatisticalInformation that represents it.

  • The codelist at-voc:received-submission-type was removed.

8HeaGyMjo8ciAAAAAASUVORK5CYII=

Issue #762 was discussed.

  • epo:ProcedureSpecificTerm, epo:ContractSpecificTerm and epo:LotSpecificTerm classes were deleted and all terms that were specialisations of these classes are now specializations of epo:Term.

PyMmJiM2lrHvazHs6y49Jjo7Ib7h2TMCgAAAAKxv7snJkcHBYYtFWodOV1NVxRhjHldfV7fw6p8AAADgOzE0NLT0f3cA+AgCAACA7wEBAGCNCAAAAL4Hb968mQOANVj9nw+REAAAAACAQAgAAAAAQCAEAAAAACAQAgAAAAAQCAEAAAAACIQAAAAAAARCAAAAAAACIQAAAAAAgRAAAAAAgEAIAAAAAEAgBAAAAAAgEAIAAAAAEAgBAAAAAAiEAAAAAAAEQgAAAAAAAiEAAAAAAIEQAAAAAIBACAAAAABAIAQAAAAAIBACAAAAABAIAQAAAAAIhAAAAAAABEIAAAAAAAIhAAAAAACBEAAAAACAQAgAAAAAQCAEAAAAACAQAgAAAAAQCAEAAAAACIQAAAAAAARCAAAAAAACIQAAAAAAgRAAAAAAgEAIAAAAAEAgBAAAAAAgEAIAAAAAEAgBAAAAAAiEAAAAAAAEQgAAAAAAAiEAAAAAAIEQAAAAAIBACAAAAABAIAQAAAAAIBACAAAAABAIAQAAAAAIhAAAAAAABEIAAAAAAAIhAAAAAACBEAAAAACAQAgAAAAAQCAEAAAAACAQAgAAAAAQCAEAAAAACIQAAAAAAARCAAAAAAACIQAAAAAAgRAAAAAAgED+B9iSzjYA55BBAAAAAElFTkSuQmCC

  • However, there are diagrams that show different points of view of specific terms. Eg, all the terms that were under epo:ProcedureSpecificTerm appear on a specific diagram as seen below. To discuss the business value for these diagrams in the future.

nz50nzPQLwJwDc8G1F9BuBAAAAAAAAAAAArwgIAAAAAAAAAADwioAAAAAAAAAAAACvCAgAAAAAAAAAAPCKgAAAAAAAAAAAAK8ICAAAAAAAAAAA8IqAAAAAAAAAAAAArwgIAAAAAAAAAADwioAAAAAAAAAAAACvCAgAAAAAAAAAAPCKgAAAAAAAAAAAAK8ICAAAAAAAAAAA8IqAAAAAAAAAAAAArwgIAAAAAAAAAADwioAAAAAAAAAAAACvCAgAAAAAAAAAAPCKgAAAAAAAAAAAAK8ICAAAAAAAAAAA8IqAAAAAAAAAAAAArwgIAAAAAAAAAADwioAAAAAAAAAAAACviP8CeNn0EpPhcDMAAAAASUVORK5CYII=

Terms related to Procedure

w9Jct7Q8BnctAAAAABJRU5ErkJggg==

Terms related to Lot

oKAfb1rcAAAAASUVORK5CYII=

Terms related to Contract

Action Points

  • To create a diagram with all the relationships of epo:LotGroup

Working Group Meeting

Date: 11/03/2025  
Participants: Victorio Bentivogli, Paul Donohoe, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Discuss new Github Issues related to eForms.

Discussions

Issue #754 was discussed:

  • The problem with the ticket is that apparently the ND-ModificationSection is repeatable.

  • The Modification Justification Vocabulary was consulted.

gI4jisM+XWIAAAAASUVORK5CYII=

  • A possible solution would be to extend the cardinality for the predicate (referring to Modified Notice Part Reference).

  • A use case was given: When the publications office changed name to OP, all the contracts had to be amended.

    • Based on that, each contract will have a single epo-not:ContractModificationNotice.

  • Predicate’s epo:relatesToEFormSectionIdentifier linking epo-con:ContractModificationInformation to adms:Identifier. cardinality was changed from [0..1] to [0..*].

4AODDhxrvygAAAABJRU5ErkJggg==

  • Issue #758 was discussed:

    • A Contract always mentions Lots not LotGroups.

    • Are there actual notices with Groups of Lots? just a few but most were not done correctly.

    • It makes sense to have a Tender for a group of lots.

    • A predicate epo:concernsLotGroup connecting epo:ContractLotCompletionInformation with epo:LotGroup was added.

    • Predicate epo:describesLotCompletion was renamed epo:concernsLot.

4PGmvzC3eLjYAAAAAASUVORK5CYII=

  • Issue #755 was discussed:

    • Both OPT-050-Lot and OPT-050-Part fields describe a status saying if the document is in an Official Language or not.

    • A solution to this would be to infer the value of this field by using the corresponding BT-708-Lot/Part and BT-737-Lot/Part fields.

    • Another problem is that since only a URL for procurement documents is provided, this URL may point to one or many procurement documents, resulting in many instances of access term.

    • Issue #732 was referenced. In that ticket it was mentioned that 708 and 737 are mutually exclusive, proving that indeed the OPT-050-Lot and OPT-050-Part values can be inferred by BT-708-Lot/Part and BT-737-Lot/Part fields. Although there is a mistake in the mappings for these fields as they go through a procurement document.

x+TiLaQBQ5tCwAAAABJRU5ErkJggg==

  • It was discussed whether that attribute epo:isProcurementDocumentRestricted of class epo:AccessTerm is needed, because it can be inferred from the Ontology.

    • It was decided that the attribute should be kept because it is mandatory for the standard forms.

    • It was also mentioned that there should not be a mapping for BT-14 in eForms since it can be inferred.

Working Group Meeting

Date: 11/03/2025  
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Achilles Dougalis
Note editor: Grzegorz Kostkowski

Agenda

  • Reviewing and refining ORSD for eAwarding.

  • Questions about selected GitHub tickets. Discussions

Discussions

  • A question was raised regarding outstanding GitHub issues that were to be prepared by the mappings team. It was clarified that the tickets had not yet been prepared.

  • The activities description for eAwarding ORSD was discussed.

    • It was clarified that the Dynamic Purchase System must be completed before the Call for Tender.

    • It was confirmed that the Award Notification is related to a Dynamic Purchase System only if an individual is awarded a contract within the DPS.

    • It was determined that the Award Notification does not belong to the eAwarding module.

    • It was noted that there is no suitable location for the DPS within the current structure.

    • It was concluded that the scope of eEvaluation, as described in the ORSD, contained activities that do not belong to the eAwarding phase.

    • A decision was made to transfer three transactions to a newly established eQualification module, which was extracted from eAwarding. These transactions include Tenderer Qualification Request, Tenderer Qualification Receipt, and Tenderer Qualification Response.

  • The participants worked on the ORSD for eQualification module.

    • A new ORSD document was created for the eQualification module based on the one for eAwarding.

    • A precise definition of eQualification was formulated, capturing its scope, which pertains to DPS and requalification systems for works.

    • The Economic Operator role was added in addition to the roles previously defined for eAwarding.

    • The distinction between DPS and the Qualification System was clarified. It was stated that the DPS is entirely electronic as for now.

    • An additional distinction was made by explaining that the Qualification System is limited in time, whereas the DPS is not.

    • The definitions of QualificationApplicationRequest and QualificationApplicationResponse were reviewed in UBL documentation. It was noted that, in UBL, the response originates from the Economic Operator, whereas the request is sent by the Buyer.

    • An explanation was provided regarding the receipt, which is a document that contains only a yes or no response.

    • A reference was made to the Directive 24, which states that the Tender Qualification Submission for DPS is considered a request to participate and is submitted by a candidate.

    • A correspondence was established between source definitions in PEPPOL and existing ePO classes to identify any missing components. It was concluded that all necessary concepts had already been modelled but some require renaming.

+PwCiawxSQSyNAAAAAElFTkSuQmCC

  • It was determined that the Call for Competition corresponds to the CompetitionNotice and appears to already be covered.

jO62gDR2kioAAAAASUVORK5CYII=

  • The use cases and natural language statements that were initially created for eAwarding were transferred to the ORSD for eQualification.

  • The eAwarding use cases and natural language statements were revised.

    • It was noted that an award decision is rarely published on the Buyer’s website and is therefore not always accessible to the Tenderer.

    • It was clarified that the Award Decision may be linked to Award Outcomes, but not to tenders.

    • It was clarified that the Award Decision is not linked to a Lot.

    • The statement regarding the standstill period was refined. It was originally stated that the standstill period lasts for 30 days, but it was adjusted to specify that the period lasts for one month.

      • It was communicated that the organization of tickets on the ePO 5.0.0 issues board had been modified, and some tickets had been categorized as low-hanging fruit.

      • Selected GitHub tickets were reviewed. Out of nine planned tasks, three were discussed, and a decision was reached for one of them.

  • The possibility of releasing a patch was discussed regarding ticket #476. It was noted that the ticket does not clearly specify the nature of the bug. A question was raised regarding why the ticket is included in the scope of version 5.0.0.

  • Ticket #711 was reviewed. It was noted that a decision had already been made during a past meeting.

  • Ticket #374 was analysed. It was stated that the issue is not of concern if it is harmless. Nonetheless, a suggestion was made to remove the attributes mentioned in the ticket if they do not serve a specific use case. A decision was made to remove these attributes, and the decision was documented in the ticket.

Action Points

To Rename epo-awa:TendererQualificationSubmision

Yuljs2kdYF4td+5qti8WufYR1sdi1r9m6WOzaR1gXi137mq2Lxa59hHWx2LWv1qqt+RYTiYTdbq9UKpADyw+dOalrf1brYrFrX78VCoXt7e3ruV3r2jusi8WufW2mhcngEkLsfHBwcHZ2ZjKZpqemQ6HQ0dFROBwuFtDbfbvRdNfeZf8fD5GeLEmLEGsAAAAASUVORK5CYII=

Working Group Meeting

Date: 06/03/2025
Participants: Victorio Bentivogli, Paul Donohoe, Natalie Muric, Pietro Palermo, Cristian Vasquez
Model editor:  Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • GitHub issue fixing for “aux: mapping” label.

Discussions

  • “aux: mapping” label

    • #738 ticket was discussed :

      • BT-684-Lot IPI regulation was discussed. That indicator is forbidden for contract notices. They are only part for result notices, 29, 30 and 32-37. It was discussed that the indicator is not needed in ePO and the ticket was closed.

    • #745 ticket was discussed, and closed.

    • #712 ticket (unpublished fields) was discussed.

      • Some changes will be done by eForms SDK 1.15 regarding concepts.

        • They will do a new section of unpublished fields at the beginning of the xml.

        • In ePO we should extend the range of ePO maskable concepts.

      • For now (regarding SDK 1.8-1.13), the current solution is satisfactory.

    • #529 ticket was discussed (Time Ontology, epo:Period)

      • It was discussed that the ePO will adopt the Time Ontology as seen in the diagram below

B3w1hqquBJQJAAAAAElFTkSuQmCC

  • TC440 Order data model latest updates were discussed Specifically it was asked that the ePO team:

    • Goes through the old Order data model and make sure that ePO covers it.

    • Fills in Order change Order response, Order agreement tabs.

    • There will be a different annex for ePO concept mappings. There will be a deadline by April.

  • During the discussion, it was mentioned that the Quotation concept is not different from a Catalogue.

Action Points

  • Account for all open issues with milestone ePO 5.0.0

    • Also suggest which open issues should go to epo 5.1.0 or 6.0.0.

Working Group Meeting

Date: 04/03/2025
Participants: Victorio Bentivogli, Veit Jahns, Natalie Muric
Model editor:  Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • Pre-award Catalogue

  • eAwarding

  • eRequest

Discussions

Further Clarifications for modeling a Pre-award Catalogue were given:

  • epo-cat:ProductSpecification was moved on the level of epo:Document and not epo-cat:PostAwardDocument.

  • At-voc-new:document-type was moved to the level of epo:Document.

sXxaHAAAAAElFTkSuQmCC

  • Predicate epo-cat:hasDocumentType was renamed as epo:documentUsedInPublicProcurement

rk+gblVSJrAAAAABJRU5ErkJggg==

  • Attribute epo-cat:hasHazardousClass of class epo-cat:AbstractItem was removed

  • Predicate Epo-cat:hasHazardousClassID was created with domain epo-cat:AbstractItem and range adms:Identifier.

HO3w+fWvAAAAAElFTkSuQmCC

  • Attribute epo-cat:hasClassificationCode [0..1] was added at the epo-cat:ItemProperty.

  • Predicate adms:identifier with domain epo-cat:ItemProperty and range adms:Identifier was added.

  • As seen in the diagram below,Class Epo:ProcurementDocumentsProvisionLine was created.

tyWPe2fttealhrxMaAhS0O71YADxsesQMubo7AfBbtv8P+L+BRnUeKsgAAAAASUVORK5CYII=

  • PreAwardCatalogueRequestLine was added.

Action Points

  • Create Github issues for 5.0.0:

  • Close 623 github issue.

  • to Investigate the reasoning behind the use of “ procurement documents provision” naming and not ”call for tenders”.

Working Group Meeting

Date: 27/02/2025
Participants: Victorio Bentivogli, Pietro, Dragos Stoica,
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eAwarding

  • eRequest

  • GitHub issue fixing for “aux: mapping” label

Discussions

  • During the meeting, the 'request for offer' diagram was discussed, and expanded.

wdWE72qoyCPUAAAAABJRU5ErkJggg==

  • Regarding the above diagram, the following notes were made:

    • Should we use pre-award Catalogue, post-award Catalogue or both?

    • In UBL, we have a reference to the Contract.

    • Proposal to move the attribute epo:hasAdditionalInformation of Class epo-req:RequestForOffer at the level of the epo:Document since there are other documents that might re-use it; it also exists at the level of the epo:Notice, which is a type of epo:Document.

    • in UBL , RequestForQuotation, the DestinationCountry is at the level of the document.

    • can the delivery information be at the line level as well?

  • Regarding GitHub issue fixing for “aux: mapping” label:

Working Group Meeting

Date: 25/02/2025
Participants: Victorio Bentivogli, Natalie Muric, Dragos Stoica,
Model editor:  Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eAwarding

  • eRequest

Discussions

  • During the meeting, the eRequest ORSD was developed.

    • The introduction was expanded: “In the procurement domain, eRequest represents a document created by the Buyer to request an offer for goods and services from a Contractor within a Framework Agreement and direct awards for procurements below threshold (small scale procurement).”

    • The Roles Involved were expanded:

      • Buyer

      • Contractor

      • Offer Issuer

    • The Activity description was expanded:

      • The Buyer sends a Request for Offer to the Contractor.

      • The Contractor receives the Request for Offer and analyses it.

      • The Offer Issuer issues and sends the Offer to the Buyer.

      • The Buyer receives the Offer and analyses it.

        • If the Offer is accepted, the Buyer writes the Contract/Order based on the Offer.

        • If the Offer is not accepted, the Buyer may ask for modifications of the Request for Offer and re-start the process.

  • During the meeting, the eAwarding ORSD was further developed.

    • The DPS was further explained by sharing this document.

    • The Description was divided into two segments: Awarding Notification and Dynamic Purchase System.

    • For the Dynamic Purchase System the following description was added: “Dynamic Purchase System

      1. The Buyer creates a Call For Competition.

      2. The Unique Responsible of the Procurement *ensures *the evidence for the Participation Conditions and the Qualification Criteria are fulfilled by Candidates proposed for Qualification.

      3. If the evidence is good, the Qualification Response is *sent *by the Unique Responsible of the Procurement to the Candidate mentioning he is accepted on the Candidate List.

      4. If the evidence is not good, the Qualification Response is *sent *by the Unique Responsible of the Procurement to the Candidate mentioning he is not accepted on the Candidate List. “

      5. A Call for Tender is created.

  • The Award Decision Notification diagram for the eAwarding module was presented and expanded. By the end of the WGM the diagram looked like this:

Xd3nvxYAAAAAAADw14YAAAAAAAC4RxAAAAAAAAD3CAIAAAAAAOAe+T9C4a4MqDrpKwAAAABJRU5ErkJggg==

  • In the above diagram epo-awa:AwardDecisionNotification was defined.

  • AwardDecision Attribute hasAdditionalNonAwardJustification became hasAwardJustification.

    • Definition was updated as follows: "Description of the reason behind an award or non-award of a given Tender.Additional information: This is generally used when the non award justification code is set to "Other" and when the Lot is awarded. It may highlight the justification of the non-award of a Tender with regard to awarded Tenders."

Action Points

Working Group Meeting

Date: 20/02/2025
Participants: Victorio Bentivogli, Natalie Muric, Dragos Stoica. Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • ESPD

  • eRequest

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

Discussions

The ESPD #413 ticket was discussed again:

  • It was mentioned that information such as the one mentioned in the ticket should be Additional Information.

  • It was decided this should not be of class cccev:Evidence, as it is currently modeled and it should be modeled differently.

  • There is a need for a superclass other than Evidence.

Information on the eRequest concept was given:

  • It is a request for an offer in a Framework agreement, and its response. It is also related with mini-competition.

#691 was discussed:

Concerning the review diagram:

  • Class epo:ReviewObject was removed.

  • Attribute epo:hasNumberOfReviewRequests of class epo:ReviewRequest was removed.

  • Attribute epo:hasRequestDate of class epo:ReviewRequest was removed.

  • Attribute epo:hasDecisionDate of class epo:ReviewDecision was removed.

XVxSWHlipzP508HXYb+TrZhqLSQMxb0WIeqsoYFEvNoNW9KGNzSvO1ku+w4BQgg0zmcHm7f9MnJafINAADwOf4Pfiay9DofS+YAAAAASUVORK5CYII=

  • Class epo:ReviewRequest became a specialization of epo:Document.

  • Class epo:ReviewDecision became a specialization of epo:Document.

  • Predicate epo:specifiesReviewRequester [0..1] with domain epo:ReviewRequest and range epo:ReviewRequester was added.

  • Predicate epo:specifiesReviewer [0..1] with domain epo:ReviewDecision and range epo:Reviewer was added.

  • Attribute epo:hasElementReference xsd:anyURI [0..*] was added to class epo:Document.

  • Attribute epo:hasNumberOfReviewRequests xsd:integer [1] was added to class epo:ReviewRequestSummary.

x+37mPe5mgmFQAAAABJRU5ErkJggg==

Concerning the completion notice relations diagram:

  • Predicate epo:announcesReviewObject [0..*] with domain epo-not:CompletionNotice and range epo:ReviewObject was removed.

BxVaz2ggl6AeAAAAAElFTkSuQmCC

  • Predicate epo:refersToReviewRequest [0..*] with domain epo-not:CompletionNotice and range epo:ReviewRequest was added.

3PY8YFIfEgAAAAAASUVORK5CYII=

Concerning the result notice relations diagram:

  • Predicate epo:announcesReviewObject [0..*] with domain epo-not:ResultNotice and range epo:ReviewObject was removed.

G4HdyAAAAABJRU5ErkJggg==

  • Predicate epo:announcesReviewRequest [0..*] with domain epo-not:ResultNotice and range epo:ReviewRequest was added.

V3Q9F4LDgAAAABJRU5ErkJggg==

Action Points

  • Create github issue for TED mappings repository informing for the changes done in this WGM regarding the review concepts.

Working Group Meeting

Date: 18/02/2025
Participants: Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eAwarding discussions

Discussions

The eAwarding Ontology Requirements Specification Document (ORSD) was further developed. Specifically:

The following Roles are involved in eAwarding:

  • Unique Responsible of the Procurement – played by a Person; it is part of the Buyer’s Organization (the head of the Organisation; the person that has the final decision)

  • Buyer

  • Tenderer

  • Winner

  • Candidate

The Award Decision is based on the Evaluation report. The Unique Responsible for the Procurement either accepts the findings of the Evaluation Report, or takes another decision (in case the winner does not fulfill all the criteria for the award of the contract).

The Activity description section was written as follows:

  1. The Award Decision is written by the Unique Responsible of the Procurement.

  2. The Unique Responsible of the Procurement *ensures *the evidences for the Participation Conditions and the Qualification Criteria are fulfilled by Tenderers proposed for an Award.

    1. If the evidences are good, the Award Decision is signed by the Unique Responsible of the Procurement.

    2. If the evidences are not good the Buyer can ask for clarifications from the non-compliant Tenderer:

      1. If the clarification confirms that the evidence is good, the Award Decision is signed by the Unique Responsible of the Procurement.

      2. If the clarification confirms that the evidence is not good, the evidences of another Tenderer(s) are checked until we reach the required number of Winners

  3. The Tenderers are notified about the result through one of the following:

    1. Award Decision is* published* on the Buyer’s website

    2. Award Notification is *sent *to the Tenderers

  4. A standstill period (while the contract cannot be signed) of one month starts from the notification to allow other Tenderers to request Review.

  5. At the end of the standstill period the Contract can be signed.

  6. No later than 30 days after the conclusion of a Contract, a Result Notice must be published.

The following Use cases were added:

Use case Description Actors Flow

The Award Decision is written

The Award Decision is* written *by the Unique Responsible of the Procurement.

Unique Responsible of the Procurement

The Unique Responsible of the Procurement writes the Award Decision based on the Evaluation Report.

Participation Conditions and the Qualification Criteria are checked

The Participation Conditions and the Qualification Criteria are assessed.

Unique Responsible of the Procurement

The Unique Responsible of the Procurement ensures the Participation Conditions and the Qualification Criteria are fulfilled by checking the evidences referenced/written in the ESPD.

Clarifications from the non-compliant Tenderer are required

If the evidences are not good the Buyer can ask for clarifications from the non-compliant Tenderer.

Unique Responsible of the Procurement,

If the clarification confirms that the evidence is good, the Award Decision is signed by the Unique Responsible of the Procurement.

The Award Decision is signed

The Award Decision is* signed* by the Unique Responsible of the Procurement.

The Unique Responsible of the Procurement signs the Award Decision.

The Tenderers are notified about the result of the procurement.

The Award Decision is published on the Buyer’s website OR an Award Notification is sent to the Tenderers.

Buyer, Tenderer

The Tenderers are notified about the result through one of the following:

It was noted that the Qualification Response should be in another module.

Working Group Meeting

Date: 13/02/2025
Participants: Peter Borresen, Dragos Stoica
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eFulfilment Receipt advice data model.

Discussions

ResponseStatus codelist was put at the level of AbstractContainer as seen on the diagram below:

H5Xn0ZjodhkAAAAASUVORK5CYII=

  • Further Questions regarding the fields of the Receipt advice data model were answered.

There was a further discussion with the ESPD team regarding ticket https://github.com/OP-TED/ESPD-EDM/issues/413:

ifgrKMX2H2zvDuRfsHvL8X1IeYSPsXONd414Af9bHOLW53p7aRQSBAAAZQsCAAAAHsRs1En5PC6dyqVR97c2CGurADxS+9tbTAYNAgCAsgUBAAAAH43LYbOYdAAeNS0EAADl6i9mow4AAMBHkcsk0hMRAI+aQacufW8DAMoBBAAAAAAAAABlBAIAAAAAAACAMgIBAAAAAAAAQBmBAAAAAAAAAKCMQAAAAAAAAABQRiAAAAAAAAAAKCMQAAAAAAAAAJQRCAAAAAAAAADKCAQAAAAAAAAAZQQCAAAAAAAAgDICAQAAAAAAAEAZ+YvZoAUAAAAAAACUif8PzaVVo+oY6acAAAAASUVORK5CYII=

  • Add a Github Issue about renaming that highlighted property seen in the diagram above in order to cover for the parts mentionerd in the https://github.com/OP-TED/ESPD-EDM/issues/413 depicted in the figures below. A possible name could be epo:canProvideEvidence Also the attribute coversAllSelectionCriteria should be at the level of the evidence.

wVeP3KRaHQkZgAAAABJRU5ErkJggg==
NEoAnahOUDlAJ0r066cE0InqBCWATlSJlAA6UZ2gBNCJKpESQCeqE5QAOlElUgLoRHWCEkAnqkRKAJ2oTlAC6ESVSAmgE9UJSgCdqBIpAXSiOkEJoBNVIt0NoP8vVgGQgLO74ooAAAAASUVORK5CYII=
YAAOCH4IflPIFWBgAAAAAAgBi0MgAAAAAAAMQubNBXAQAAAAAAAHjQygAAAAAAABCDVgYAAAAAAIAYtDIAAAAAAADEoJUBAAAAAAAgBq0MAAAAAAAAMWhlAAAAAAAAiEErAwAAAAAAQAxaGQAAAAAAAGLQygAAAAAAABCDVgYAAAAAAIAYtDIAAAAAAADEoJUBAAAAAAAgBq0MAAAAAAAAMWhlAAAAAAAAiEErAwAAAAAAQAxaGQAAAAAAAGIXGOsrAAAAAAAAADxoZQAAAAAAAIhBKwMAAAAAAEAMWhkAAAAAAABi0MoAAAAAAAAQg1YGAAAAAACA2P8DpCv8rdb3tWQAAAAASUVORK5CYII=
TNKnbu3LlixYrFixdv2bLlf0tyk6VLl3bdaR4MeAbxCNnW1tZwSuUbNmw48HitCLNu3bpkG4mjEUk4EolE09EJ4UgkEt0ESTgSiUTTkYQjkUgk4UgkEk1HEo5EIpGEI5FINB1JOBKJRBKORCLRdCThSCQSSTgSiUTTkYQjkUgk4UgkEk1HEo5EIpGEI5FINB1JOBKJRBKORCLRdCThSCQSSTgSiUTTkYQjkUgk4UgkEk1HEo5EIpGEI5FINB1JOBKJxL+CcIwbN2716tWNJxKJRLfB3LlzZ86cGSnmE4lE98TKlSsnTpzYRMLxzjvv9OvXb9CgQZr570Qi0f0wadKkvn373nXXXdYejecSiUT3AA4wYMAAZAAraCQKB8EhE462trYFCxbMnj27tbX174lEovvB3G9paZk5c+acOXMazyUSiW4DTGDJkiVYQSNROAgOmXAkEolEIpFIHCqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOpJwJBKJRCKRaDqScCQSiUQikWg6knAkEolEIpFoOv4PU9iXAmDDf2wAAAAASUVORK5CYII=

Action Points

  • Create a Github Issue to implement Object Line Identifier with the predicate SalesOrderLineID.

  • Add a Github Issue about renaming that highlighted property mentioned above.

Working Group Meeting

Date: 11/02/2025
Participants: Natalie Muric, Dragos Stoica
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

  • eAwarding ORSD

Discussions

A new definition for the epo-sub:ESPD was given according to the diagram below:

YhHDjQwf8HyKKBj3YrX28AAAAASUVORK5CYII=
iYEVMACWswAAAABJRU5ErkJggg==
8feK1wv8CGG+r2ojXfSqQZ20QwFEwxBxz7fuK3+P10AOg8b1wyWAAAAAElFTkSuQmCC

Issue #734 was updated accordingly, and epo-sub:ESPD and ePO-acc:ESPDRequest: were updated accordingly.

The WG started discussing about the ORSD for the eAwarding module.

ESPD-EDM https://github.com/OP-TED/ESPD-EDM/issues/423 and https://github.com/OP-TED/ESPD-EDM/issues/413 issues were discussed:

  • #423:

    • eForms and UBL are not aligned, ESPD is aligned with UBL.

    • A qualifying party has a codelist that describes the role. So ESPD is covered by this. 423 can thus be closed.

  • #413

    • It was discussed that although the specific field mentioned in issue #413 covers multiple lists or equivalent certificates, in the ePO there are no Lists.

    • It was mentioned that the information conveyed by that specific field is not used as an evidence for any criterion and that it should be modelled as additional information and not evidence.

Working Group Meeting

Date:30/01/2025  
Participants: Peter Borresen, Natalie Muric
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Alignment with PEPPOL for eFulfilment #569.

Discussion

  • Alignment with PEPPOL for eFulfilment #569.

    • Definitions and clarifications were given for specific Business Groups, and Business Terms in the Receipt Advice data model.

Action Points

  • Create a Github Issue: Harmonize all post award document classes such as despatch advise to use
    The epo:associatedWith rather than a direct link to an epo:Document.
    Also add a link from the lines to a document.

z8BM81bbOD8bgAAAABJRU5ErkJggg==
fxg9J6ikIYVjAAAAAElFTkSuQmCC
Aym7ClPzXPmo+qggYSvxVLTyi8B58A0khqRu2+wrKAAAAAElFTkSuQmCC
dNUa2Q9w4AkAAAAASUVORK5CYII=

Working Group Meeting

Date: 28/01/2025
Participants: Victorio Bentivogli, Paul Donohoe, Ioannis Fountoukidis, Yves Jordan, Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

Discussions

Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

During the meeting, definitions for the following BTs that appearon the Annex of Regulation 2023/2884:

  • BT-776 did not have any impact on the Ontology.

  • BT-810

    • Is the indicator attribute epo:isCompliantToEnergyEfficiencyDirective needed? It was decided that this indicator will not be modelled since if it is true we will have an instance of epo:EnergyEfficiencyInformation.

  • BT-811

    • Two code lists are needed:

      • Energy-efficiency-Item (already in ePO)

      • Energy-efficiency-Basis (not in ePO)

    • As a result, at-voc:energy-efficiency-basis was created, and linked to epo:EnergyEfficiencyInformation. (see diagram below).

gfJHGSczAVwAAAABJRU5ErkJggg==

  • Create two diagrams in ePO (1 for competiton and 1 for Lot-result) for epo:EnergyEfficiencyInformation class.

  • 813 and 814 are paired.

  • BT-814 :

    • It was discussed that this will be implemented with the SDK implementation., not with the Regulation 2023/2884.

    • Two predicates connecting epo:EnergyEfficiencyInformation to epo:Quantity will be epo:hasConcumptionQuantity and epo:hasSavingsQuantity.

    • The guides/gde_004_eed.pdf · main · eProcurement Group / eForms Group / Docs · GitLab Guide was consulted.

    • At the level of epo:EnergyEfficiencyInformation we will have epo:EnergyEfficiencyItem.

m+CvNcVjQo46cQQojo9v8AKFBifwwbFF4AAAAASUVORK5CYII=

Working Group Meeting

Date: 23/01/2025  
Participants: Peter Borresen, Paul Donohoe, Yves Jordan
Model editor: Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • eFulfilment meeting regarding Receipt Advice.

  • Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]

  • Phttps://github.com/OP-TED/ePO/issues/529[otential problem with modelling of epo:Period ]ePO #529

  • Mapping of at-voc:timeperiod to the OWL Time Ontology ePO #681

Discussions

During the first part of the WGM, eFulfilment and specifically Receipt Advice was discussed: Definitions and clarifications were given for specific Business Groups, and Business Terms in the Receipt Advice data model.

Regarding the “Unmappable eForms fields in PIN, CEI and T02 notice subtypeshttps://github.com/OP-TED/ePO/issues/726[#726]” github issue:

  • Examples of T01 , and T02 eForms were given to the WGM.

  • Regarding the following fields: Τhey are just for T02 and are about a Tender, so they should be put in a class on the level of epo:TenderAwardOutcome. This class should be named epo:TenderAwardOutcomeInformation. Another class: epo:ContractCondition was added.

    • OPP-080-Tender: Kilometers Public Transport: Represented as a predicate to the epo:Quantity class.

    • OPP-035-Tender: Revenues Allocation of tickets sales code uses the following codelist With only one value.

    • OPP-032-Tender: Revenues Allocation: Add epo:hasTicketsSalesRevenueAllocation xsd:decimal, [0..1] attribute on epo:TenderAwardOutcomeInformation.

    • OPP-030-Tender: Contract conditions Code: uses the following codelist.

    • OPP-031-Tender: Contract Conditions Description (other than revenue allocation): epo:hasContractConditionsDescription rdf:plainLiteral. [0..1] attribute on epo:ContractConditio.n

    • OPP-033-Tender: Penalties and Rewards Code: has only one value (found here). Not going to implement.

    • OPP-034-Tender: Penalties and Rewards Description: epo:hasPenaltiesAndRewardsDescription rdf:plainLiteral [0..1] attribute to to epo:TenderAwardOutcomeInformation.

KCzrishwAAAPy6IAAAACDbpXdNkIUgAAAAvygIAAAAyHbbCZCNPj9SAADwS4AAAAAAAAAA4AGBAAAAAAAAAOABgQAAAAAAAADgAYEAAAAAAAAA4AGBAAAAAAAAAOABgQAAAAAAAADgAYEAAAAAAAAA4AGBAAAAAAAAAOABgQAAAAAAAADgAfltO7kJAAAAAAAAeCAgAAAAAAAAAHhAIAAAAAAAAAB4QCAAAAAAAAAAeED+H2itRRxdk7YeAAAAAElFTkSuQmCC

  • BT-127-Notice:No modification will happen for now.

cXfckNAKrHAJr3udMi82hMAPAfCbarVEStLmMAAAAASUVORK5CYII=

Action Points

  • Create a Github issue: For the Receipt Advice ePO diagram: To represent the action-code and reject-reasons codelists also at the level of the epo-ful:ReceiptAdvice.

mqVvqbbcXMAAAAAElFTkSuQmCC

Working Group Meeting

Date: 21/01/2025
Participants: Paul Donohoe, Yves Jordan, Dragos Stoica Model editor: Andreea Passare Note editor: Achilles Dougalis

Agenda

  • Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

Discussions

Regarding Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726:

Regarding OPT-070-Lot:

  • An example of a Call For Expressions Of Interest document was presented (F_CEI_EN_DRAFT_2019-03-25.pdf). The ePO team used the document to create a CM diagram for Call For Expressions Of Interest.

  • The latest Notice-types.json eforms document was consulted.

  • Class epo-not:PINTransportationNotice was created as seen on the diagram below.

M78XFT1lwMAAAAAASUVORK5CYII=

  • Class epo-not:CANTransportationNotice was created as seen on the diagram below.

s5jrpLAZ8rpz6aY3x9XxWs+f8BnMPcbaw09RIAAAAASUVORK5CYII=

  • It appears that class epo-not:CallForExpressionOfInterest was already implemented in the ePO as epo-not:NoticeCEI. To discuss the removal of epo-not:CallForExpressionOfInterest in a future WGM.

Regarding OPT-071-Lot :

  • The Customer-service codelist was found and does not currently exist in ePO and will be added.

  • It was mentioned that For T02 and T01, epo:LotGroup is Forbidden

  • Class epo:QualityTargetInformation was created; it should always be linked to an epo:ContractTerm.

  • at-voc:customer-service was created on the level of epo:QualityTargetInformation. They are both mandatory.

  • Attribute epo:hasQualityTargetDescription was created.

J5sV+TexYlQAAAABJRU5ErkJggg==

Regarding Assets in a Contract: (they are all for T02):

  • OPP-020-Contract: Assets related contract extension indicator. Class epo:Asset was created.

  • OPP-021-Contract: Used asset Added dct:description [0..1] for epo:Asset.

  • OPP-022-Contract: Significance (%): Added attribute epo:hasSignificance rdf:PlainLiteral. To be further discussed as concept name may change in the future

  • OPP-023-Contract: Predominance (%): Added attribute epo:hasPredominance rdf:PlainLiteral. To be further discussed as concept name may change in the future

4OUzXEkIrXwAAAABJRU5ErkJggg==

Contract terms and other information of a Tender: These are all T02 Notices. It was decided that the WGM will work on the above fields next WGM on 23/01/2025.

OPP-040-Procedure: Main Nature - Sub Type: at-voc:transport-service was created.

a1HXP6NuObggAAAuHogAMBnpJBJpOL1a8vxBgHgOnD8XQBSOCAAAK4SCAAAAAAAAACuEQgAAAAAAAAArhEIAAAAAAAAAK4RCAAAAAAAAACuEQgAAAAAAAAArhEIAAAAAAAAAK4RCAAAAAAAAACuEQgAAAAAAAAArhEIAAAAAAAAAK4RCAAAAAAAAACukf8Pzg4zhbqF9dAAAAAASUVORK5CYII=

Action Points

Working Group Meeting

Date: 16/01/2025  
Participants: Peter Borresen, Paul Donohoe, Yves Jordan, Natalie Muric, Dragos Stoica,
Model editor:  Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

  • Alignment with PEPPOL for eFulfilment #569.

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

  • Potential problem with modelling of epo:Period #529

  • Mapping of at-voc:timeperiod to the OWL Time Ontology #681

Discussions

Regarding the alignment with PEPPOL for eFulfilment #569, it was decided that the alignment between PEPPOL business term requirements and ePO eFulfilment module will continue with the Receipt Advice Data model.

Regarding the new BTs described in Regulation 2023/2884 to ePO concepts.https://github.com/OP-TED/ePO/issues/691[#691:]

  • BT-749: It was discussed that although BT-749 was removed from the regulation, no removal of an ePO concept was needed.

  • BT-681: An attribute for epo:ProcurementElement was added for this. epo:appliesForeignSubsidiesRegulation xsd:boolean[0..1]

aD+H80jDfNt6R55AAAAAElFTkSuQmCC
r83XUG1MDSgAAAABJRU5ErkJggg==

  • A use-case is required to find out in what procurement phase should this codelist be used. This will be done in the future as part of describing the Procurement Process. A link to the Digigrow guide on how to use this codelist was provided: https://code.europa.eu/eproc/eforms/docs/-/blob/main/guides/gde_001_fsr.md?ref_type=heads

  • BT-684: It was decided that this BT will not be implemented for now.

  • BT-681 : Should points to epo:LotAwardOutcome. .

  • BT-685 is for the Tender. There is currently no codelist for this. It should go directly to the epo:LotAwardOutcome class. (via the epo:InternationalProcurementInstrumentMeasuresInformation Class seen in the diagram below)

  • BT-686 : Attribute epo:hasNumberOfTendersConcerned as seen in the diagram below.

  • BT-687 : at-voc:international-procurement-instrument-application As seen in the diagram below.

  • BT-688 :Attribute epo:hasPublicInterestExceptionJustification as seen in the diagram below.

  • The International Procurement Instrument Application vocabulary was consulted. It was mentioned that the Digigrow guide (link above) better explains the above mentioned BTs.

QAAAAASUVORK5CYII=

The epo:InternationalProcurementInstrumentMeasuresInformation Class

  • It is important to note that these IPIs are for third world countries or Tenders that have third country subsidiaries.

Continue working on Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

  • Lot tenderingTerms Fields were discussed:

    • OPT-070-Lot : Class epo:CallForExpressionOfInterest is a typeOf epo:Notice.

Working Group Meeting

Date: 14/01/2025  
Participants: Paul Donohoe, Yves Jordan, Natalie Muric
Model editor:  Andreea Passare
Note editor: Achilles Dougalis

Agenda

  • Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726

  • Map the new BTs described on Regulation 2023/2884 to ePO concepts. #691

Discussions

Regarding #726

  • The following IDs are mandatory in UBL but not required in eForms, so there is no need to map them to ePO either for Lot or Part:

    • OPT-111

    • OPT-112

    • OPT-113

  • The following Classes were implemented: (also depicted on the diagram below) For the following fields:

    • OPT-110-Lot-FiscalLegis

    • OPT-110-Part-FiscalLegis

    • OPT-120-Lot-FiscalLegis

    • OPT-120-Part-FiscalLegis

    • OPT-130-Lot-FiscalLegis

    • OPT-130-Part-FiscalLegis

    • epo:LegislativeDocumentation

    • epo:FiscalLegalDocumentation

    • epo:EnvironmentalLegalDocumentation

    • epo:EmploymentLegalDocumentation

    • epo:Class epo:Documentation was created that is a generalisation of the above Documentation classes.

    • Predicate providesDocumentation was added fromTaxInformationProvider to epo:Documentation

8iFAAAAAASUVORK5CYII=

  • #691

    • ΒG-700 was mapped to epo:QualificationCriterion.

    • ΒT-806: The codelist used is in eForms (exclusion-grounds-source) and it has 3 values: epo-notice, epo-sub-espd (this might be epo-acc-espd) and epo-procurement-document. We will create 3 attributes at the level of epo:QualificationCriteria for each value:

      • epo:hasQualificationCriteriaStatedinNotice

      • epo:hasQualificationCriteriaStatedinESPDRequest

      • epo:hasQualificationCriteriaStatedinProcurementDocuments.

    • BT-821: uses the same codelist as BT-806.

    • BT-67(a), BT-77(b): epo:hasExclusionGroundType predicate connected to at-voc:exclusion-ground was added.

    • BT-748 At-voc:usage will not be used anymore. Instead we create predicates epo:doesNotRequireSelectionCriterionType epo:hasUnknownUsageOfSelectionCriterionType connected to at-voc:selection-criterion codelist. that will be used in case a specific selection criterion is not used or is not yet known.

TED Developer Docs

This website is managed by: Publications Office of the European Union

Need Help?

Follow us

Legal

About us

Other services

Discover more on europa.eu

Contact the EU

Social Media

EU institutions and bodies